FIG. 1 is a block diagram that illustrates a typical mechanism for communicating program data between a host computer and a smart card. Smart cards 110 typically communicate with other computers 100 via APDUs (Application Protocol Data Units). The APDU protocol is specified in International Standard ISO/IEC 7816-3. An APDU includes either a command 115 or a response 120 message. A smart card 110, via a smart carder reader 105, receives a command APDU 115 from a host computer 100, executes the instruction specified in the command 115 and replies to the host computer 100 with a response APDU 120. Command APDUs 115 and response APDUs 120 are exchanged alternately between a card 110 and a host computer 100.
According to the APDU protocol, APDU messages comprise two structures 200, 250. One structure 200 includes a header 205 with fields CLA 215, INS 220, P1 225 and P2 230 and a body 210 with fields Lc 235, Data 240, and Le 245, and is used by a host application on a loading terminal to send commands to the card. The other structure 250 includes a body 255 with a data field 265 and a trailer with fields SW1 270, SW2 275, and is used by the card to send responses back to the host application. The former is referred to as the command APDU (C-APDU) and the latter is referred to as the response APDU (R-APDU). Their structures 200, 250 are illustrated in FIGS. 2A and 2B, respectively. Some C-APDU components are optional
Java Card™ technology enables programs written in the Java™ programming language to run on smart cards and other resource-constrained devices. Java Card™ technology is described in Z. Chen, Java Card™ Technology for Smart Cards (2000).
Turning now to FIG. 3, a block diagram that illustrates loading a converted applet (CAP) file is presented. The Java Card™ Virtual Machine (JCVM) comprises an on-card portion that includes the Java Card™ bytecode interpreter 345 and an off-card portion called a converter 310. Taken together, the interpreter 345 and the converter 310 implement all the virtual machine functions, including loading Java™ class files 300 and executing them with a particular set of semantics. The converter 310 loads and pre-processes the class files 300 that comprise a Java Card™ program that may be structured in one or more packages and produces a CAP (converted applet) file 350. The CAP file 350 is then loaded on a Java Card™ technology-enabled smart card 330 and executed by the interpreter 345. The CAP file 350 includes an executable binary representation of the classes in a Java™ package 355. The Java Card™ interpreter 345 provides runtime support of the Java™ language execution model.
In Java Card™ technology, the mechanisms to download and install a CAP file 350 are embodied in a unit called the installer 340. The Java Card™ installer 340 resides within the card 330. It cooperates with an off-card installation program 320. The off-card installation program 320 transmits the executable binary and possibly other data in a CAP file 350 to the installer 340 running on the card 330 via a loading terminal 325. The installer 340 writes the binary into the smart card memory, links it with the other classes that have already been placed on the card 330 and creates and initializes any data structures that are used internally by the Java Card™ runtime environment. An optional on-card verifier 335 performs bytecode verification of downloaded code before the downloaded code is interpreted by bytecode interpreter 345.
The APDU protocol limits the size of the payload or data field (reference numeral 240 of FIG. 2) to a small number of bytes (typically less than 128) determined by the restricted size of RAM. Data structures larger than the limitation must be split among the payload portion of multiple APDUs. This splitting is typically performed without regard to the data content. For example, a particular APDU may contain a portion of one data structure and a portion of another data structure. This is explained in more detail below, with reference to FIG. 4.
Turning now to FIG. 4, a flow diagram that illustrates loading a CAP file from the perspective of a loading terminal is presented. At 400, a CAP file is received. At 405, the CAP file and associated authentication data is split amongst multiple APDUs. At 410, the APDUs are transmitted to the target smart card according to the APDU protocol.
Turning now to FIG. 5, a flow diagram that illustrates loading a CAP file from the perspective of a smart card is presented. At 500, the CAP file is reassembled in the smart card. At 505, the reassembled CAP file is decrypted. At 510, the decrypted CAP file data is authenticated. In another solution, the CAP file is authenticated and then decrypted. In yet another solution, the CAP file is communicated without encryption. At 515, the content of the authenticated CAP file is installed on the smart card.
Turning now to FIG. 6, a flow diagram that illustrates reassembling a CAP file in a smart card is presented. At 600, an APDU is received. At 605, the APDU is stored in a persistent mutable memory such as an EEPROM (electrically erasable programmable read-only memory). Alternatively, the APDU payload is not stored in a persistent mutable memory. At 610, receipt of the APDU is acknowledged. At 615, a determination is made regarding whether another APDU needs to be processed. Additional APDUs are processed beginning at 600.
Turning now to FIG. 7, a block diagram that illustrates modifying a stored program having link data to resolve static references is presented. Card memory 700 represents card memory before using embedded link data (704, 712, 730) to link executable code segments (702, 706, 708, 710, 712, 716, 718, 720, 722, 724, 726, 728, 732). Card memory 750 represents card memory after the embedded link data (704, 712, 730) has been used to link executable code segments (702, 706, 708, 710, 712, 716, 718, 720, 722, 724, 726, 728, 732). Referring to card memory 700, method “A1A” code 702 calls method “A1C” 708, method “A2A” code 712 calls method “B1A” 720 and method “B2A” code 728 calls method “B1D” 726. Method “AlA” link data 704 comprises an indication of how to resolve the reference to method “A1C” 708. Method “A1A” link data 704 may additionally comprise an indication of how method “A1A” code 702 must be modified. Likewise, method “A2A” link data 714 comprises an indication of how to resolve the reference to method “B1A” 720. Method “A2A” link data 714 may additionally comprise an indication of how method “A2A” code 712 must be modified. Additionally, method “B2A” link data 730 comprises an indication of how to resolve the reference to method “B1D” 726. Method “B2A” link data 730 may additionally comprise an indication of how method “B2A” code 728 must be modified. Referring to card memory 750 of FIG. 7, symbolic references to called methods have been replaced, with the addresses of the called methods and the link data is not stored.
Unfortunately, storing the re-created CAP file in a persistent mutable memory and then processing the CAP file contents to create linked executable code requires a significant amount of available memory and is time consuming.
Accordingly, a need exists in the prior art for a method and apparatus for communicating program data between a host computer and a smart card that is relatively efficient. A further need exists for such a solution that is relatively secure. Yet another need exists for such a solution that detects when program data has been tampered with.